Setting breakpoints in optimized instructions

ABSTRACT

A method, computer-readable storage medium, and computer system are provided. In an embodiment, in response to a command that requests setting a breakpoint at a line in a module, a determination is made whether a snapshot instruction exists before a machine instruction that implements a source statement at the line. If the snapshot instruction exists before the machine instruction that implements the source statement at the line, the breakpoint is set at the machine instruction that implements the source statement at the line. If the snapshot instruction does not exist before the machine instruction that implements the source statement at the line, the module is recompiled to add the snapshot instruction before the machine instruction that implements the source statement.

FIELD

An embodiment of the invention generally relates to computer systems andmore particularly to computer systems that execute optimizedinstructions.

BACKGROUND

Computer systems typically comprise a combination of computer programsand hardware, such as semiconductors, transistors, chips, circuitboards, storage devices, and processors. The computer programs arestored in the storage devices and are executed by the processors.Locating, analyzing, and correcting suspected faults in a computerprogram is a process known as “debugging.” Bugs are problems, faults, orerrors in a computer program. Typically, a programmer uses anothercomputer program commonly known as a debugger to debug the program underdevelopment.

Conventional debuggers typically support three primary types ofoperations, which a computer programmer may request via a userinterface. A first type is a breakpoint or address watch operation,which permits a programmer to identify with a breakpoint a preciseinstruction at which to halt execution of the program by the processor,or identify via an address watch, a memory location for the processor tomonitor for content modification, at which time the program's executionis halted. The debugger may set a breakpoint by replacing a validinstruction at the location specified by the programmer with an invalidinstruction, which causes a system exception when the program attemptsto execute the invalid instruction, giving control of the processor tothe debugger. The debugger may set an address watch via a function ofthe processor. As a result, when a program is executed by the debugger,the program executes on the processor in a normal fashion until thebreakpoint is reached or the contents of the monitored memory locationare written to, at which time the debugger halts execution of theprogram. A second type is a step operation, which permits a computerprogrammer to cause the processor to execute instructions in a programeither one-by-one or in groups. After each instruction or group ofinstructions are executed, the debugger then halts execution of theprogram. Once the execution of the program is halted, either by step orbreakpoint operations, conventional debuggers provide a third type ofoperation, which displays the content that is stored at various storagelocations, in response to requests by the programmer. By this debuggingprocess of halting the program at various instructions and examining thecontent of various storage locations, the programmer might eventuallyfind the storage location whose stored content, such as an instructionor data, is incorrect or unexpected.

SUMMARY

A method, computer-readable storage medium, and computer system areprovided. In an embodiment, in response to a command that requestssetting a breakpoint at a line in a module, a determination is madewhether a snapshot instruction exists before a machine instruction thatimplements a source statement at the line. If the snapshot instructionexists before the machine instruction that implements the sourcestatement at the line, the breakpoint is set at the machine instructionthat implements the source statement at the line. If the snapshotinstruction does not exist before the machine instruction thatimplements the source statement at the line, the module is recompiled toadd the snapshot instruction before the machine instruction thatimplements the source statement. In an embodiment, the previous versionof the object code is overwritten in memory with the object code thatcontains the snapshot instruction.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

FIG. 1 depicts a high-level block diagram of an example system forimplementing an embodiment of the invention.

FIG. 2 depicts a block diagram of an example module, according to anembodiment of the invention.

FIG. 3 depicts a block diagram of an example data structure for debugdata, according to an embodiment of the invention.

FIG. 4 depicts a block diagram of example object code, according to anembodiment of the invention.

FIG. 5 depicts a flowchart of example processing for a set breakpointcommand, according to an embodiment of the invention.

It is to be noted, however, that the appended drawings illustrate onlyexample embodiments of the invention, and are therefore not considered alimitation of the scope of other embodiments of the invention.

DETAILED DESCRIPTION

Referring to the Drawings, wherein like numbers denote like partsthroughout the several views, FIG. 1 depicts a high-level block diagramrepresentation of a server computer system 100 connected to a clientcomputer system 132 via a network 130, according to an embodiment of thepresent invention. The terms “server” and “client” are used herein forconvenience only, and in various embodiments a computer system thatoperates as a client computer in one environment may operate as a servercomputer in another environment, and vice versa. The mechanisms andapparatus of embodiments of the present invention apply equally to anyappropriate computing system.

The major components of the computer system 100 comprise one or moreprocessors 101, a main memory 102, a terminal interface 111, a storageinterface 112, an I/O (Input/Output) device interface 113, and a networkadapter 114, all of which are communicatively coupled, directly orindirectly, for inter-component communication via a memory bus 103, anI/O bus 104, and an I/O bus interface unit 105.

The computer system 100 contains one or more general-purposeprogrammable central processing units (CPUs) 101A, 101B, 101C, and 101D,herein generically referred to as the processor 101. In an embodiment,the computer system 100 contains multiple processors typical of arelatively large system; however, in another embodiment the computersystem 100 may alternatively be a single CPU system. Each processor 101executes instructions stored in the main memory 102 and may comprise oneor more levels of on-board cache.

In an embodiment, the main memory 102 may comprise a random-accesssemiconductor memory, storage device, or storage medium (either volatileor non-volatile) for storing or encoding data and programs. In anotherembodiment, the main memory 102 represents the entire virtual memory ofthe computer system 100, and may also include the virtual memory ofother computer systems coupled to the computer system 100 or connectedvia the network 130. The main memory 102 is conceptually a singlemonolithic entity, but in other embodiments the main memory 102 is amore complex arrangement, such as a hierarchy of caches and other memorydevices. For example, memory may exist in multiple levels of caches, andthese caches may be further divided by function, so that one cache holdsinstructions while another holds non-instruction data, which is used bythe processor or processors. Memory may be further distributed andassociated with different CPUs or sets of CPUs, as is known in any ofvarious so-called non-uniform memory access (NUMA) computerarchitectures.

The main memory 102 stores or encodes a debugger 150, modules 152,object code 154, a breakpoint table 155, debug data 156, an integrateddevelopment environment (IDE) 158, and a compiler 160. Although thedebugger 150, the modules 152, the object code 154, the breakpoint table155, the debug data 156, the IDE 158, and the compiler 160 areillustrated as being contained within the memory 102 in the computersystem 100, in other embodiments some or all of them may be on differentcomputer systems and may be accessed remotely, e.g., via the network130. The computer system 100 may use virtual addressing mechanisms thatallow the programs of the computer system 100 to behave as if they onlyhave access to a large, single storage entity instead of access tomultiple, smaller storage entities. Thus, while the debugger 150, themodules 152, the object code 154, the breakpoint table 155, the debugdata 156, the IDE 158, and the compiler 160 are illustrated as beingcontained within the main memory 102, these elements are not necessarilyall completely contained in the same storage device at the same time.Further, although the debugger 150, the modules 152, the object code154, the breakpoint table 155, the debug data 156, the IDE 158, and thecompiler 160 are illustrated as being separate entities, in otherembodiments some of them, portions of some of them, or all of them maybe packaged together.

In an embodiment, the debugger 150, the modules 152, the object code154, the IDE 158, and the compiler 160 comprise instructions orstatements that execute on the processor 101 or instructions orstatements that are interpreted by instructions or statements thatexecute on the processor 101, to carry out the functions as furtherdescribed below with reference to FIGS. 2, 3, 4, and 5. In anotherembodiment, the debugger 150, the IDE 158, and the compiler 160 areimplemented in hardware via semiconductor devices, chips, logical gates,circuits, circuit cards, and/or other physical hardware devices in lieuof, or in addition to, a processor-based system. In an embodiment, thedebugger 150, the modules 152, the object code 154, the IDE 158, and/orthe compiler 160 comprise data in addition to instructions orstatements.

The compiler 160 compiles the modules 152, which comprises source codeor statements, into the object code 154, which comprises machineinstructions. In an embodiment, the compiler 160 translates the modules152 into an intermediate form before translating the intermediate forminto the object code 154. In an embodiment, the compiler 160 is ajust-in-time compiler that executes as part of an interpreter. In anembodiment, the compiler 160 is an optimizing compiler. In variousembodiments, the compiler 160 performs peephole optimizations, localoptimizations, loop optimizations, inter-procedural or whole-programoptimizations, machine code optimizations, or any other optimizations toreduce the amount of time the object code 154 uses to execute and/or toreduce the amount of memory that the object code 154 uses to execute. Inan embodiment, the optimizations performed by the compiler 160 resultsin the values of variables used by the object code 154 being kept inregisters and not necessarily immediately stored to memory at the timethat the object code 154 modifies the values.

The breakpoint table 155 comprises identifiers of the breakpoints thatthe debugger 150 set, line numbers in the module 152 where the debugger150 set the breakpoints, and machine instructions that the debugger 150swapped out of the object code 154, replacing the swapped machineinstructions with invalid opcodes. In response to the processor 101attempting to execute the invalid opcodes, the processor 101 raises aninterrupt, which the debugger 150 receives, giving the debugger 150control. When the user is ready to restart the object code 154, thedebugger 150 replaces the invalid opcode with the swapped-outinstruction and starts the object code 154 executing, again, on theprocessor 101.

The memory bus 103 provides a data communication path for transferringdata among the processor 101, the main memory 102, and the I/O businterface unit 105. The I/O bus interface unit 105 is further coupled tothe system I/O bus 104 for transferring data to and from the various I/Ounits. The I/O bus interface unit 105 communicates with multiple I/Ointerface units 111, 112, 113, and 114, which are also known as I/Oprocessors (IOPs) or I/O adapters (IOAs), through the system I/O bus104.

The I/O interface units support communication with a variety of storageand I/O devices. For example, the terminal interface unit 111 supportsthe attachment of one or more user I/O devices 121, which may compriseuser output devices (such as a video display device, speaker, and/ortelevision set) and user input devices (such as a keyboard, mouse,keypad, touchpad, trackball, buttons, light pen, or other pointingdevice). A user may manipulate the user input devices using a userinterface, in order to provide input data and commands to the user I/Odevice 121 and the computer system 100, and may receive output data viathe user output devices. For example, a user interface may be presentedvia the user I/O device 121, such as displayed on a display device,played via a speaker, or printed via a printer.

The storage interface unit 112 supports the attachment of one or moredisk drives or direct access storage devices 125 (which are typicallyrotating magnetic disk drive storage devices, although they couldalternatively be other storage devices, including arrays of disk drivesconfigured to appear as a single large storage device to a hostcomputer). In another embodiment, the storage device 125 may beimplemented via any type of secondary storage device. The contents ofthe main memory 102, or any portion thereof, may be stored to andretrieved from the storage device 125, as needed. The I/O deviceinterface 113 provides an interface to any of various other input/outputdevices or devices of other types, such as printers or fax machines. Thenetwork adapter 114 provides one or more communications paths from thecomputer system 100 to other digital devices and computer systems 132;such paths may comprise, e.g., one or more networks 130.

Although the memory bus 103 is shown in FIG. 1 as a relatively simple,single bus structure providing a direct communication path among theprocessors 101, the main memory 102, and the I/O bus interface 105, infact the memory bus 103 may comprise multiple different buses orcommunication paths, which may be arranged in any of various forms, suchas point-to-point links in hierarchical, star or web configurations,multiple hierarchical buses, parallel and redundant paths, or any otherappropriate type of configuration. Furthermore, while the I/O businterface 105 and the I/O bus 104 are shown as single respective units,the computer system 100 may, in fact, contain multiple I/O bus interfaceunits 105 and/or multiple I/O buses 104. While multiple I/O interfaceunits are shown, which separate the system I/O bus 104 from variouscommunications paths running to the various I/O devices, in otherembodiments some or all of the I/O devices are connected directly to oneor more system I/O buses.

In various embodiments, the computer system 100 is a multi-usermainframe computer system, a single-user system, or a server computer orsimilar device that has little or no direct user interface, but receivesrequests from other computer systems (clients). In other embodiments,the computer system 100 is implemented as a desktop computer, portablecomputer, laptop or notebook computer, tablet computer, pocket computer,telephone, smart phone, pager, automobile, teleconferencing system,appliance, or any other appropriate type of electronic device.

The network 130 may be any suitable network or combination of networksand may support any appropriate protocol suitable for communication ofdata and/or code to/from the computer system 100 and the computer system132. In various embodiments, the network 130 may represent a storagedevice or a combination of storage devices, either connected directly orindirectly to the computer system 100. In another embodiment, thenetwork 130 may support wireless communications. In another embodiment,the network 130 may support hard-wired communications, such as atelephone line or cable. In another embodiment, the network 130 may bethe Internet and may support IP (Internet Protocol). In anotherembodiment, the network 130 is implemented as a local area network (LAN)or a wide area network (WAN). In another embodiment, the network 130 isimplemented as a hotspot service provider network. In anotherembodiment, the network 130 is implemented an intranet. In anotherembodiment, the network 130 is implemented as any appropriate cellulardata network, cell-based radio network technology, or wireless network.In another embodiment, the network 130 is implemented as any suitablenetwork or combination of networks. Although one network 130 is shown,in other embodiments any number of networks (of the same or differenttypes) may be present.

The computer system 132 may comprise some or all of the hardware and/orcomputer program elements of the computer system 100.

FIG. 1 is intended to depict the representative major components of thecomputer system 100, the network 130, and the computer system 132. But,individual components may have greater complexity than represented inFIG. 1, components other than or in addition to those shown in FIG. 1may be present, and the number, type, and configuration of suchcomponents may vary. Several particular examples of such additionalcomplexity or additional variations are disclosed herein; these are byway of example only and are not necessarily the only such variations.The various program components illustrated in FIG. 1 and implementingvarious embodiments of the invention may be implemented in a number ofmanners, including using various computer applications, routines,components, programs, objects, modules, data structures, etc., and arereferred to hereinafter as “computer programs,” or simply “programs.”

The computer programs comprise one or more instructions or statementsthat are resident at various times in various memory and storage devicesin the computer system 100 and that, when read and executed by one ormore processors in the computer system 100 or when interpreted byinstructions that are executed by one or more processors, cause thecomputer system 100 to perform the actions necessary to execute steps orelements comprising the various aspects of embodiments of the invention.Aspects of embodiments of the invention may be embodied as a system,method, or computer program product. Accordingly, aspects of embodimentsof the invention may take the form of an entirely hardware embodiment,an entirely program embodiment (including firmware, resident programs,micro-code, etc., which are stored in a storage device) or an embodimentcombining program and hardware aspects that may all generally bereferred to herein as a “circuit,” “module,” or “system.” Further,embodiments of the invention may take the form of a computer programproduct embodied in one or more computer-readable medium(s) havingcomputer-readable program code embodied thereon.

Any combination of one or more computer-readable medium(s) may beutilized. The computer-readable medium may be a computer-readable signalmedium or a computer-readable storage medium. A computer-readablestorage medium, may be, for example, but not limited to, an electronic,magnetic, optical, electromagnetic, infrared, or semiconductor system,apparatus, or device, or any suitable combination of the foregoing. Morespecific examples (an non-exhaustive list) of the computer-readablestorage media may comprise: an electrical connection having one or morewires, a portable computer diskette, a hard disk (e.g., the storagedevice 125), a random access memory (RAM) (e.g., the memory 102), aread-only memory (ROM), an erasable programmable read-only memory(EPROM) or Flash memory, an optical fiber, a portable compact discread-only memory (CD-ROM), an optical storage device, a magnetic storagedevice, or any suitable combination of the foregoing. In the context ofthis document, a computer-readable storage medium may be any tangiblemedium that can contain, or store, a program for use by or in connectionwith an instruction execution system, apparatus, or device.

A computer-readable signal medium may comprise a propagated data signalwith computer-readable program code embodied thereon, for example, inbaseband or as part of a carrier wave. Such a propagated signal may takeany of a variety of forms, including, but not limited to,electro-magnetic, optical, or any suitable combination thereof. Acomputer-readable signal medium may be any computer-readable medium thatis not a computer-readable storage medium and that communicates,propagates, or transports a program for use by, or in connection with,an instruction execution system, apparatus, or device. Program codeembodied on a computer-readable medium may be transmitted using anyappropriate medium, including but not limited to, wireless, wire line,optical fiber cable, Radio Frequency, or any suitable combination of theforegoing.

Computer program code for carrying out operations for aspects ofembodiments of the present invention may be written in any combinationof one or more programming languages, including object orientedprogramming languages and conventional procedural programming languages.The program code may execute entirely on the user's computer, partly ona remote computer, or entirely on the remote computer or server. In thelatter scenario, the remote computer may be connected to the user'scomputer through any type of network, including a local area network(LAN) or a wide area network (WAN), or the connection may be made to anexternal computer (for example, through the Internet using an InternetService Provider).

Aspects of embodiments of the invention are described below withreference to flowchart illustrations and/or block diagrams of methods,apparatus (systems), and computer program products. Each block of theflowchart illustrations and/or block diagrams, and combinations ofblocks in the flowchart illustrations and/or block diagrams may beimplemented by computer program instructions embodied in acomputer-readable medium. These computer program instructions may beprovided to a processor of a general purpose computer, special purposecomputer, or other programmable data processing apparatus to produce amachine, such that the instructions, which execute via the processor ofthe computer or other programmable data processing apparatus, createmeans for implementing the functions/acts specified by the flowchartand/or block diagram block or blocks. These computer programinstructions may also be stored in a computer-readable medium that candirect a computer, other programmable data processing apparatus, orother devices to function in a particular manner, such that theinstructions stored in the computer-readable medium produce an articleof manufacture, including instructions that implement the function/actspecified by the flowchart and/or block diagram block or blocks.

The computer programs defining the functions of various embodiments ofthe invention may be delivered to a computer system via a variety oftangible computer-readable storage media that may be operatively orcommunicatively connected (directly or indirectly) to the processor orprocessors. The computer program instructions may also be loaded onto acomputer, other programmable data processing apparatus, or other devicesto cause a series of operational steps to be performed on the computer,other programmable apparatus, or other devices to produce acomputer-implemented process, such that the instructions, which executeon the computer or other programmable apparatus, provide processes forimplementing the functions/acts specified in the flowcharts and/or blockdiagram block or blocks.

The flowchart and the block diagrams in the figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods, and computer program products, according to variousembodiments of the present invention. In this regard, each block in theflowcharts or block diagrams may represent a module, segment, or portionof code, which comprises one or more executable instructions forimplementing the specified logical function(s). In some embodiments, thefunctions noted in the block may occur out of the order noted in thefigures. For example, two blocks shown in succession may, in fact, beexecuted substantially concurrently, or the blocks may sometimes beexecuted in the reverse order, depending upon the functionalityinvolved. Each block of the block diagrams and/or flowchartillustration, and combinations of blocks in the block diagrams and/orflow chart illustrations, can be implemented by special purposehardware-based systems that perform the specified functions or acts, incombinations of special purpose hardware and computer instructions.

Embodiments of the invention may also be delivered as part of a serviceengagement with a client corporation, nonprofit organization, governmententity, or internal organizational structure. Aspects of theseembodiments may comprise configuring a computer system to perform, anddeploying computing services (e.g., computer-readable code, hardware,and web services) that implement, some or all of the methods describedherein. Aspects of these embodiments may also comprise analyzing theclient company, creating recommendations responsive to the analysis,generating computer-readable code to implement portions of therecommendations, integrating the computer-readable code into existingprocesses, computer systems, and computing infrastructure, metering useof the methods and systems described herein, allocating expenses tousers, and billing users for their use of these methods and systems. Inaddition, various programs described hereinafter may be identified basedupon the application for which they are implemented in a specificembodiment of the invention. But, any particular program nomenclaturethat follows is used merely for convenience, and thus embodiments of theinvention are not limited to use solely in any specific applicationidentified and/or implied by such nomenclature. The exemplaryenvironments illustrated in FIG. 1 are not intended to limit the presentinvention. Indeed, other alternative hardware and/or programenvironments may be used without departing from the scope of embodimentsof the invention.

FIG. 2 depicts a block diagram of an example module A 152, according toan embodiment of the invention. The module A 152 comprises any number ofroutines, such as the routine A 201, the routine B 202, and the routineC 203. The module A 152 further comprises an ID (identifier) field 215,which identifies the version of the module 152. The example routine A201 comprises example source statements 210 and corresponding lines 205at which the source statements 210 are stored in the routine 201. Eachof the source statements 210 is identified by its respective line 205and exists or is stored at its respective line 205, which are numberedsequentially from beginning to end of the routine 201 or the module 152.The source statements 210 are human-readable source code.

FIG. 3 depicts a block diagram of an example data structure for debugdata 156, according to an embodiment of the invention. The debug data156 comprises example records 302, 304, 306, 308, 310, 312, and 314,each of which comprises an example module ID (identifier) field 320, aline field 322, an offset field 324, and a snapshot flag field 326. Themodule ID field 320, in each record, identifies one of the modules 152and optionally a routine within the module 152. The line field 322, ineach record, identifies a line 205 in the module 152 identified by themodule identifier field 320, in the same record. The offset field 324,in each record, specifies the offset (or number of bytes, words, ordouble words), from the beginning of the object code 154, at which themachine instructions are stored in the object code 154 that the compiler160 created to implement the source statement 210 (when executed) at theline identified by the line field 322, in the same record of the debugdata 156. The snapshot flag field 326, in each record, specifies whetheror not snapshot instructions exist in the object code 154 before themachine instructions that implement the source statement at the lineidentified by the line field 322, specified by the same record in thedebug data 156 and after the machine instructions that implement thesource statement at the immediately preceding line. Snapshotinstructions are machine instructions that, when executed by theprocessor 101, store all values of all variables referenced anywhere bythe module 152 from registers specified by the compiler (the registersare not specified or referenced by source statements in the module 152)to locations in the memory 102 that represent or contain the variables.If the value of the snapshot flag field 326 indicates true, then thesnapshot instructions exist, and if execution of the object code 154halts at the machine instructions at the offset 324, then the values ofthe variables are present in the memory 102. If the value of thesnapshot flag field 326 indicates false, then the snapshot instructionsdo not exist, so at the time of execution of the machine instructions atthe offset 324, the current values of the variables might be present inthe memory 102 or might be present in registers created by the compiler160 but not present in the memory 102.

FIG. 4 depicts a block diagram of example object code 154, according toan embodiment of the invention. The object code 154 comprises exampleobject code 402 for the routine A, unused space 404 for the routine A,object code 406 for the routine B, unused space 408 for the routine B,object code 410 for the routine C, and unused space 412 for the routineC. The unused space 404 is allocated to the routine A, the unused space408 is allocated to the routine B, and the unused space 412 is allocatedto the routine C. The object code 402, when executed on the processor101, implements the routine A of the module A 152. The object code 406,when executed on the processor 101, implements the routine B of themodule A 152. The object code 410, when executed on the processor 101,implements the routine C of the module A 152.

The object code 402 comprises an offset field 420 and a machineinstruction field 422. The offset field 420, in each entry, comprisesthe offset, distance, or amount of storage between the start of theobject code 154 (or alternatively the start of the object code 402) andthe entry. The debugger 150 maps the lines in the module 152 to themachine instructions in the object code 154 that implement the sourcestatement in the lines via matching values in the offset field 324 (FIG.3) and the offset field 420 (FIG. 4) in the object code 402. Thus, forexample, “load r1, A” at offset 200F represents the machine instructionthat implements line 1 of the module 152 and, when executed, reads thevalue from the memory location of variable A into register R1. “StoreR1, A; Store R2, B; Store R3, C” at offsets 2870 and 3060 represent themachine instructions of the snapshot instructions, which store thevalues from the registers R1, R2, and R3 to the memory locations thatstore the respective variables A, B, and C, which are all of thevariables referenced by the example module 152. The snapshotinstructions are immediately before their associated machineinstructions, e.g., the “Store R1, A; Store R2, B; Store R3, C” atoffset 2870 are immediately before “JMP 4500” (which implements thesource statement “CALL F(A)” at line 3 of the module 152) andimmediately after “INC R1” (which implements the source statement“A=A+1” at line 2 of the module 152). For convenience of exposition, themachine instruction field 422 in FIG. 4 illustrates assembly languageinstructions, but the actual machine instructions executed by theprocessor 101 are binary codes.

FIG. 5 depicts a flowchart of example processing for a set breakpointcommand, according to an embodiment of the invention. Control begins atblock 500. Control then continues to block 505 where the debugger 150receives a set breakpoint command from a user via the user I/O device121 or the client computer 132 via the network 130. The set breakpointcommand identifies a line in a module 152. The set breakpoint commandrequests that the debugger 150 set a breakpoint at a machine instructionin the object code 154 that implements the source statement in theidentified line, so that the object code 154, when executed, haltsexecution just before executing that machine instruction (and afterexecution of the immediately preceding machine instruction). Thedebugger 150 receives the set breakpoint command while execution of theobject code 154 is halted.

Control then continues to block 510 where the debugger 150 determineswhether snapshot instructions exist immediately before an instruction inthe object code 154 that implements the source statement at theidentified line in the module 152 and after the immediately precedinginstruction that implements the source statement at the line immediatelypreceding the identified line in the module 152. If the determination atblock 510 is true, then snapshot instructions exist immediately beforean instruction in the object code 154 that implements the sourcestatement at the identified line in the module 152 and after theimmediately preceding instruction that implements the source statementat the line immediately preceding the identified line in the module 152,so control continues to block 515 where the debugger 150 sets thebreakpoint at the machine instruction in the object code 154 thatimplements the source statement of the line and updates the breakpointtable 155. In an embodiment, the debugger 150 sets the breakpoint at themachine instruction by copying the machine instruction and the linenumber to the breakpoint table 155 and replacing the machine instructionin the object code 154 with an invalid opcode. Control then continues toblock 599 where the logic of FIG. 5 returns. In various embodiments, theexecution of the object code 154 continues or restarts following thereturn at block 599 or the user may initiate another set breakpointcommand or another debug command.

If the determination at block 510 is false, then snapshot instructionsdo not exist immediately before an instruction in the object code 154that implements the source statement at the identified line in themodule 152 and after the immediately preceding instruction thatimplements the source statement at the line immediately preceding theidentified line in the module 152, so control continues to block 520where the debugger 150 determines whether execution of the object code154 is halted at the instruction that implements the source statement atthe identified line (identified by the set breakpoint command) in themodule 152.

If the determination at block 520 is true, then execution of the objectcode 154 is halted at the instruction that implements the sourcestatement at the identified line in the module 152, so control continuesto block 525 where the debugger 150 returns an error to the user thatinitiated the set breakpoint command. Control then continues to block599 where the logic of FIG. 5 returns without setting a breakpoint atthe identified line and without recompiling the module 152. In variousembodiments, the execution of the object code 154 continues or restartsfollowing the return at block 599 or the user may initiate another setbreakpoint command or another debug command.

If the determination at block 520 is false, then execution of the objectcode 154 is not halted at the instruction that implements the sourcestatement at the identified line in the module 152, so control continuesto block 530 where the IDE 158 reads the ID 215 from the module 152,determines the versions of the routines in the module 152 from the ID215, and determines compile options. In response to reading the ID andthe compile options, control continues to block 535 where the IDE 158requests the compiler 160 to add snapshot instructions to the objectcode 154 immediately before all the machine instructions that implementthe source statement at the identified line and immediately before allthe machine instructions at which snapshots have been inserted duringthis debug session. The compiler 160 receives the request.

In response to the request, control continues to block 540 where thecompiler 160 determines whether the size of the snapshot sizeinstructions is greater than the size of the unused space allocated tothe routine that contains the machine instructions that implement thesource statement at the identified line. If the determination at block540 is true, then the size of the snapshot size instructions is greaterthan the size of the unused space allocated to the routine that containsthe machine instructions that implement the source statement at theidentified line, so not enough unused space exists to add the snapshotinstructions to the object code 154, so control continues to block 525where the debugger 150 returns an error to the user that initiated theset breakpoint command. Control then continues to block 599 where thelogic of FIG. 5 returns without setting a breakpoint at the requestedline and without recompiling the module 152. In various embodiments, theexecution of the object code 154 continues or restarts following thereturn at block 599 or the user may initiate another set breakpointcommand or another debug command.

If the determination at block 540 is false, then the size of thesnapshot size instructions is less than or equal to the size of theunused space allocated to the routine that contains the machineinstructions that implement the source statement at the identified line,so enough unused space exists to add the snapshot instructions to theobject code 154, so control continues to block 545 where the compiler160 recompiles the module 152 into the object code 154, insertingsnapshot instructions immediately before the machine instructions thatimplement the source statement at the identified line and insertingsnapshot instructions immediately before all machine instructions thatimplement source statements at lines with a snapshot flag 326 set totrue. Thus, the compiler 160 adds the snapshot instructions before allmachine instructions at which breakpoints were set prior to therecompiling. The compiler 160 stores the instructions of the object codeinto the memory 102, overwriting the existing instructions of the objectcode 154. In various embodiments, the compiler 160 overwrites the entireobject code 154 or just the routines in which the compiler addedsnapshot instructions. The compiler 160 updates the record in the debugdata 156 for the identified line to set the snapshot flag 326 to true.

Control then continues to block 550 where the debugger 150 sets abreakpoint at the machine instruction that implements the identifiedline, sets breakpoints for all breakpoints in the breakpoint table 155at their machine instructions, and updates the breakpoint table 155.Thus, after the recompiling of the module 152, the debugger 150 setsbreakpoints at all of the machine instructions at which breakpoints hadpreviously been set (before the recompiling occurred). Control thencontinues to block 599 where the logic of FIG. 5 returns. In variousembodiments, the execution of the object code 154 continues or restartsfollowing the return at block 599 or the user may initiate another setbreakpoint command or another debug command.

In this way, in an embodiment of the invention, when execution of theobject code 154 halts at a breakpoint, the values of variables are inthe memory 102, even for the object code 154 that is optimized, wherethe values of variables may be temporarily stored in registers and notimmediately stored to the memory 102.

The terminology used herein is for the purpose of describing particularembodiments only and is not intended to be limiting of the invention. Asused herein, the singular forms “a,” “an,” and “the” are intended toinclude the plural forms as well, unless the context clearly indicatesotherwise. It will be further understood that the terms “comprises”and/or “comprising,” when used in this specification, specify thepresence of the stated features, integers, steps, operations, elements,and/or components, but do not preclude the presence or addition of oneor more other features, integers, steps, operations, elements,components, and/or groups thereof. In the previous detailed descriptionof exemplary embodiments of the invention, reference was made to theaccompanying drawings (where like numbers represent like elements),which form a part hereof, and in which is shown by way of illustrationspecific exemplary embodiments in which the invention may be practiced.These embodiments were described in sufficient detail to enable thoseskilled in the art to practice the invention, but other embodiments maybe utilized and logical, mechanical, electrical, and other changes maybe made without departing from the scope of the present invention. Inthe previous description, numerous specific details were set forth toprovide a thorough understanding of embodiments of the invention. But,embodiments of the invention may be practiced without these specificdetails. In other instances, well-known circuits, structures, andtechniques have not been shown in detail in order not to obscureembodiments of the invention.

Different instances of the word “embodiment” as used within thisspecification do not necessarily refer to the same embodiment, but theymay. Any data and data structures illustrated or described herein areexamples only, and in other embodiments, different amounts of data,types of data, fields, numbers and types of fields, field names, numbersand types of rows, records, entries, or organizations of data may beused. In addition, any data may be combined with logic, so that aseparate data structure is not necessary. The previous detaileddescription is, therefore, not to be taken in a limiting sense.

What is claimed is:
 1. A method for obtaining up-to-date values ofvariables at a breakpoint during a debugging session of an optimizedsoftware code comprising: in response to a command that requests settinga breakpoint at a line in a module, determining whether a snapshotinstruction exists before a machine instruction that implements a sourcestatement at the line; if the snapshot instruction exists before themachine instruction that implements the source statement at the line,setting the breakpoint at the machine instruction that implements thesource statement at the line; and if the snapshot instruction does notexist before the machine instruction that implements the sourcestatement at the line, recompiling the module to add the snapshotinstruction before the machine instruction that implements the sourcestatement; wherein the snapshot instruction when executed stores a valueof a variable referenced by the module from a register to a location inmemory that represents the variable.
 2. The method of claim 1, whereinthe recompiling the module further comprises: adding the snapshotinstruction before all machine instructions at which breakpoints wereset prior to the recompiling.
 3. The method of claim 2, furthercomprising: after the recompiling, setting breakpoints at all of themachine instructions at which breakpoints were set before therecompiling.
 4. The method of claim 1, further comprising: performingthe recompiling if a size of the snapshot instruction is less than orequal to a size of unused space in memory that is allocated to a routinethat comprises the machine instruction that implements the sourcestatement.
 5. The method of claim 1, further comprising: setting thebreakpoint at the machine instruction that implements the sourcestatement at the line after the recompiling.
 6. The method of claim 1,wherein the recompiling the module adds a plurality of snapshotinstructions before the machine instruction that implements the sourcestatement, wherein the plurality of snapshot instructions, whenexecuted, store values of all variables referenced by the module thatare saved in registers to locations in memory that represent thevariables.
 7. A non-transient computer-readable storage medium encodedwith instructions, wherein the instructions when executed obtainup-to-date values of variables at a breakpoint during a debuggingsession of an optimized software code comprise: in response to a commandthat requests setting a breakpoint at a line in a module, determiningwhether a snapshot instruction exists before a machine instruction thatimplements a source statement at the line; if the snapshot instructionexists before the machine instruction that implements the sourcestatement at the line, setting the breakpoint at the machine instructionthat implements the source statement at the line; and if the snapshotinstruction does not exist before the machine instruction thatimplements the source statement at the line, recompiling the module toadd the snapshot instruction before the machine instruction thatimplements the source statement; wherein the snapshot instruction whenexecuted stores a value of a variable referenced by the module from aregister to a location in memory that represents the variable.
 8. Thecomputer-readable storage medium of claim 7, wherein the recompiling themodule further comprises: adding the snapshot instruction before allmachine instructions at which breakpoints were set prior to therecompiling.
 9. The computer-readable storage medium of claim 8, furthercomprising: after the recompiling, setting breakpoints at all of themachine instructions at which breakpoints were set before therecompiling.
 10. The computer-readable storage medium of claim 7,further comprising: performing the recompiling if a size of the snapshotinstruction is less than or equal to a size of unused space in memorythat is allocated to a routine that comprises the machine instructionthat implements the source statement.
 11. The computer-readable storagemedium of claim 7, further comprising: setting the breakpoint at themachine instruction that implements the source statement at the lineafter the recompiling.
 12. The computer-readable storage medium of claim7, wherein the recompiling the module adds a plurality of snapshotinstructions before the machine instruction that implements the sourcestatement, wherein the plurality of snapshot instructions, whenexecuted, store values of all variables referenced by the module thatare saved in registers to locations in memory that represent thevariables.
 13. A computer system for obtaining up-to-date values ofvariables at a breakpoint during a debugging session of an optimizedsoftware code comprising: a processor; and memory communicativelycoupled to the processor, wherein the memory is encoded withininstructions, wherein the instructions when executed on the processor,comprise in response to a command that requests setting a breakpoint ata line in a module, determining whether a snapshot instruction existsbefore a machine instruction that implements a source statement at theline, wherein the snapshot instruction when executed by the processorstores a value of a variable referenced by the module from a register toa location in the memory that represents the variable, if the snapshotinstruction exists before the machine instruction that implements thesource statement at the line, setting the breakpoint at the machineinstruction that implements the source statement at the line, and if thesnapshot instruction does not exist before the machine instruction thatimplements the source statement at the line, recompiling the module toadd the snapshot instruction before the machine instruction thatimplements the source statement.
 14. The computer system of claim 13,wherein the recompiling the module further comprises: adding thesnapshot instruction before all machine instructions at whichbreakpoints were set prior to the recompiling.
 15. The computer systemof claim 14, wherein the instructions further comprise: after therecompiling, setting breakpoints at all of the machine instructions atwhich breakpoints were set before the recompiling.
 16. The computersystem of claim 13, wherein the instructions further comprise:performing the recompiling if a size of the snapshot instruction is lessthan or equal to a size of unused space in the memory that is allocatedto a routine that comprises the machine instruction that implements thesource statement.
 17. The computer system of claim 13, wherein theinstructions further comprise: setting the breakpoint at the machineinstruction that implements the source statement at the line after therecompiling.
 18. The computer system of claim 13, wherein therecompiling the module adds a plurality of snapshot instructions beforethe machine instruction that implements the source statement, whereinthe plurality of snapshot instructions, when executed, store values ofall variables referenced by the module that are saved in registers tolocations in memory that represent the variables.